1. Field of the Invention
The present disclosure relates to distributed system architectures, and particularly to systems and methods for typing distributed objects in a distributed object system.
2. Related Art
A “distributed system architecture” or “distributed system” as used herein is generally one in which the computer processes comprising the distributed system execute on different physical machines connected by a computer network. A “distributed process” as used herein is generally a computer process capable of executing in a distributed system. FIG. 1 is a block diagram illustrating a distributed system at the abstract level. In FIG. 1, process 9 executes on local computer 1 and consists of a sequence of four distributed sub-processes P1, P2, P3, P4. Sub-processes P1 and P3 execute locally (illustrated as processes A and B), and sub-processes P2 and P4 execute remotely. In this illustration, sub-process P4 executes entirely on remote computer 7 (illustrated as process D), whereas sub-process P2 consists of two further sub-processes, P2.1 19 executing on remote computer 3 (illustrated as process B1), and P2.2 21 executing on remote computer 5 (illustrated as process B2). In this illustration, therefore, execution of process 9 on local computer 1 requires local execution of two distributed sub-processes (P1 and P3) and remote execution of three sub-processes (P2.1, P2.2 and P4). Additionally, process 9 may itself constitute a distributed process if it is invocable as a sub-process by other remote processes.
A “distributed system infrastructure” or “distributed infrastructure” as used herein refers the program logic needed to support the functionalities of a distributed system architecture. For example, this may include program logic for establishing and maintaining a connection with a remote computer, marshalling data and instructions over a computer network to and from processes, and providing communication protocols, name translations, and access control measures. Another important functionality provided by modern distributed system architectures is location transparency or object virtualization. This functionality enables programmers or users to generally manipulate distributed processes in a single “logical space.” Thus, for example, a programmer skilled in a particular programming language invokes processes regardless of physical location using the same familiar procedure calls provided by the programming language syntax applicable in the local address space; the infrastructure logic automatically provides the necessary remote procedure recognition, remote connections, data marshalling, and name translations needed for invoking the remote process.
A “distributed object system” is a distributed system in which the distributed processes are modeled programatically as objects. Modeling computational processes as objects is a well-known technique called object-oriented programming. In object-oriented programming, programmers encapsulate processes with associated data in relatively self-contained modules called classes, and create new processes and associated data by extending existing classes. A particular implementation of a class is called an object, and the processes implemented by the object are called methods. Methods in turn are exposed for use by other objects via interfaces which typically define the object and data types and sequences passed to and from the object. Objects are typically coded in object-oriented programming languages, such as Java or C++, which support the mechanisms giving object-oriented techniques advantages over traditional procedural coding techniques; these include the well-known advantages of, for example, data encapsulation, polymorphism, inheritance, and dynamic binding. In many distributed object systems, objects (or legacy applications) may be coded in a variety of programming languages (either object-oriented languages or procedural languages) employing different forms of programming language-specific interfaces. Thus, distributed systems often define a standard language for representing programming language-specific interfaces to the distributed infrastructure; distributed objects may therefore communicate with each other-via the standard interface language—called an “interface definition language” or “IDL”—even though they are coded in different programming languages. Programmers generally code IDL interfaces for objects directly in the IDL language, or use programming language-specific compilers to read objects and perform the necessary translations automatically. The “type” of a computation entity, such as a resource (as defined below), refers generally to the determinate set of properties belonging to the entity that are typically defined in reference to a determinate set operations performable by the entity or upon the entity. Thus, in typical distributed object systems, because remote objects are only exposed via their interfaces, the type of the remote object is typically defined by its interfaces.
Prior art distributed systems have a number of disadvantages, especially if applied to large-scale, dynamic and loosely-coupled computing domains, such as the Internet. In this context, large numbers of objects are continually changing in terms of number and characteristics; objects (or their methods and attendant interfaces) may, for example, be continually fine-tuned, added or subtracted from the distributed system. In this context, infrastructure mechanisms providing for run-time discovery of desired objects becomes increasingly important as old object references become obsolete or replaceable by new, improved objects. Prior art distributed architectures, however, provide limited mechanisms for dynamically discovering objects because remote objects are typically exposed only via their interfaces, and thus described and discoverable solely by their interfaces. The “type” of a computation entity, such as a resource (defined below), is used herein to refer generally to a determinate set of properties belonging to the entity that is typically defined in reference to the operations performable by the entity or upon the entity. Thus, in typical distributed object systems, because the operational logic of remote objects is hidden behind their interfaces, the type of the remote object is typically known only by its interfaces. In such systems, however, the expressive or descriptive capacity of object interfaces is limited, which, in turn, limits the ability to develop flexible and fine-grained discovery mechanisms which directly depend upon the descriptive mechanisms of the objects.
As a consequence, resource discovery mechanisms in typical distributed system that rely upon interface typing mechanisms have limited flexibility and ability to distinguish among objects in large object domains. In other words, as the number of objects increases, the ability to flexibly distinguish closely-related objects in terms of interface-based descriptions becomes increasingly strained, and discovery mechanisms built upon such an architecture become increasingly limited in their ability to accurately identify suitable objects. For example, numerous objects executing document printing services may be offered under an object interface name “printer” having methods “print” and “status,” and yet differ significantly in the type of services performed; the objects may significantly differ, for example, in terms of print quality, stationary choices, capacity, equipment, physical location, costs, speed of delivery, types of documents, and other factors. Discovery mechanisms limited in their searching capacities to the interface elements “printer,” “print” and “status” therefore have limited ability to discover complex objects in large-scale, diverse object domains.
Prior art interface-based typing mechanisms have an additional disadvantage. In the large, loosely-coupled Internet domain, for example, successful development of a large, viable market of objects may require specialization in how the service objects are delivered to clients over the computer network. In particular, specialization in the advertising, discovery and development of service objects may be needed. Interface-based typing systems, as discussed above, may not provide a sufficiently flexible object description mechanism to support specialized development of such service object markets.